杂事
自从过年回来工作以来，发生了好多杂七杂八的事。结了skyline业务实时报警项目的第一版，这也是我从头到尾参与的第一个项目。承蒙主管信任，我参与了项目从构建开始的每一步过程，从基础服务搭建，业务流程梳理，到后端逻辑规划，数据库设计，前端页面设计，虽然这是一个小型的项目并不复杂，但也从中学到很多，真应该抽空写一下项目复盘，留个坑以后写。。
在skyline项目收尾的时候，柱哥找我谈了话，问我愿不愿意担任项目组的前端team leader，emmm很开心的答应了，一开始我以为只是承担组内部分协调任务，结果一周被开了大大小小七八个会（或约谈），才知道这是阿里外包管理部推动IDU外包独立交付的一环，意在推动外包管理从资源供给转型到独立交付，外包团队自行承担项目组的管理工作，分担主管的管理负担。云安全和IOT事业部的五个外包供应商和十几个TL都是这期交付转型的参与者，了解之后我才觉的这事一点也不轻松。。
上上周我收集了团队内存在的问题，整理了一份导图，提了6个解决意见，之后都变成了我的交付考核指标，考核期3个月，6月份的时候有一次阿里组织的答辩，通过答辩就算是正式的teamleader了。想想自己这么快就被委以重任还有点小激动。。在这两三周里，每天都在忙着处理指派过来的需求，学习管理知识，开各种各样的会，很充实，碰到柱哥这样的主管+老师，是我的幸运。每天都能感觉到自己在成长，真的是一件很幸福的事。剩下唯一的问题，就是我有多努力了。
项目管理
包哥之前建议我去考软考高级项目管理，现在看来还是有先见之明的，那一大本大厚书我是真没啃动多少，但是现在有了些感性的认识，再去看那本大厚书觉得不再那么不着边际了。上周公司派了一位PM做分享，只有短短半个小时时间，但是我觉得说的点都很到位，整理一下。
业务内容
每一个开发都有必要了解业务，这个之前听王坚博士的分享也提过这一点，当然如果需求文档设计文档接口文档三者都齐全的话，开发也不是什么难事，但是目前的状态下，业务方给不出详尽的文档，很多页面需求甚至业务方自己都没想明白，这个时候就会陷入边改边写边写边改的窘境，如果开发人员了解业务，知道需求是为了解决什么问题的话，不仅能又快又好的写出页面，甚至还能在需求没理清的情况下帮助业务方澄清需求，设计页面。实际上，开发人员弄清业务节省的是沟通成本，而沟通也是开发流程中最耗时的部分。
管理需求
“主管想要一个什么样的团队？”抛去积极向上能打硬仗加的了班熬的起夜有追求有梦想这种普适的特点来说，每个环境需要的团队特质也会有些细微的差别，在这个时间点上如果能实现组内自治，我想应该就是主管最大的需求。
“如何建设这样一个团队？”团队每个人都有自己的想法，从之前的散养状态到受额外监管的状态很大程度上会侵占他们的舒适区，自然而然的产生反抗和抵触情绪，作为组里年纪最小资历最浅的人，很高兴有组员支持我的工作，接受我的安排，但也有人不以为然，不过我想，多去沟通，达成共识，是让他理解我的工作的基础。
针对开发过程的优化
简单的把开发过程梳理为三个阶段，需求排期->开发->交付。这三个阶段里做不同的优化方案，可以达到高质量高效率的交付能力。
需求排期
排期阶段的第一步是区分需求的紧急程度，第二步是澄清筛选出来的需求，第三步结合前两步的结果，评估需求是否需要重排。
紧急需求没什么好说的，在需求澄清的时候，必须先理好需求关系，弄清前置条件，是否需要别的团队合作，需求文档是否详细等等，总的来说就是做好一切开发准备，尽量保证开发过程不会被阻塞导致做到一半做不下去的情况。
开发
确定好需求之后，开始需求评审过程，通过UED设计和设计评审之后再投入开发，需求评审和UED设计、设计评审是不断反复的过程，直至敲定终稿，这个过程应该尽量留下文档，确定好之后如果再有变更，应该发起变更流程，让变更的操作变的昂贵，这样才能在设计阶段迫使业务方理清思路，防止频繁变更，也能在需求频繁变更导致延期的时候及时把锅甩出去。
PM/TL的岗位职责
在现阶段情况下，主管对接TL，TL对接外包同学，中间PM这一环是缺失的，所以TL还要承担一部分PM的职责，做需求的分配，任务分发，风险控制，缺陷管理等等等等。。
告知
在项目有风险时及时告知业务方，做好规避准备。实际上平时也应该去做一下人员备份，防止请假、离职造成的延期风险。
进度跟踪
每天都去了解组员的开发进度，是否有困难，是否需要帮助，预计多久能做完。进度管理的意义倒是不大，主要是让组员获取关注感，感觉到每天的工作有人在关心，促进一部分工作热情。
节点关注
在需求的完工节点和交付节点做好确认和汇报，安排测试和review环节，确保无风险，高质量交付。
小记
目前很多工作都在从0到1的阶段，今天推行了缺陷控制流程，提出了代码互测和代码规范，希望一个月下来，团队的交付质量和交付能力能有所提高。
